Web Services - Definição, Características e Tipos SOAP e REST

PDWA5 Henrique Dias Pastor Web Service Definição Web services são aplicações modulares autodescritas e autocontidas que podem ser conectadas e acopladas a outros webservices IBM Web Services são componentes de software com baixo fator de acoplamento utilizados por meio de padrões de tecnologia Internet Um Web Service representa uma função de negócio ou um serviço que pode ser acessado por uma outra aplicação Gartner Web Service Principais Características Fornecem serviços a clientes dispersos na Web Podem ser facilmente localizados na rede Interfaces são bem definidas e autodescritas Empregam padrões da Internet Formato de dados Comunicação Se comunicam facilmente através de firewalls Consiste em uma tecnologia aberta independente de linguagem e de plataforma Web Service Web service é uma solução utilizada para integração e comunicação entre diferentes aplicações Por meio de um web service você pode disponibilizar funções ou mensagens para qualquer outra aplicação na internet ou em aplicações corporativas internamente Além disso também é possível acessar consumir funções e mensagens de outros web services A comunicação é realizada através do formato XML usando o protocolo HTTP Através do XML que é um formato universal é possível que aplicações rodando em plataformas diferentes se comuniquem simplesmente traduzindo seus dados para XML antes da comunicação O protocolo HTTP é o mais utilizado na internet É através desse protocolo que você pode navegar pelos sites usando seu navegador de preferência Neste contexto o PHP nos fornece funções para trabalhar com web services Web Service Web Service Desktop Mobile Web App Web Service Os dois principais tipos de comunicação com Web Service são SOAP REST Web Service Web Services Baseado em SOAP Baseado em REST REST REpresentational State Transfer SOAP WSDL UDDI XML SOAP SOAP é um protocolo de comunicação baseado em XML que permite que aplicações troquem informações utilizando o protocolo geralmente HTTP Mais especificamente SOAP é um protocolo para acessar um Web Service SOAP significa Simple Object Access Protocol Por seguir um padrão W3C é independente de plataforma e independente de linguagem de programação É simples e extensível Por trabalhar com o protocolo HTTP que é o protocolo mais comum utilizado na internet ele facilita a comunicação evitando que a transmissão seja bloqueada por um firewall ou proxy SOAP Baseiase num protocolo que envelopa o conteúdo associado a WSDL que é uma linguagem que descreve os serviços oferecidos Barbosa 2013 SOAP Registro de serviços Provedor de serviço Serviço cliente 1 Registrase SOAP 2 Busca serviço SOAP 3 Usa serviço SOAP SOAP A descrição da interface de um web service SOAP é especificado em um documento XML chamado de WSDL Web Services Description Language O WSDL descreve o Web service e contém informações de como acessá lo Ele especifica a localização do serviço e quais são os seus métodos disponíveis Portanto caso esteja criando um web service que deseja disponibilizar para outros programas será preciso criar o arquivo WSDL WSDL WSDL É a sigla de Web Services Description Language padrão baseado em XML O WSDL é uma especificação desenvolvida pelo W3C e também é extensível para permitir a descrição dos serviços e suas mensagens independentemente dos formatos de mensagem e dos protocolos de rede que sejam usados No entanto é comum usarse o MIME Multipurpose Internet Mail Extensions e o HTTPSOAP O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML este providencia a documentação necessária para se chamar um sistema distribuído e o procedimento necessário para que esta comunicação se estabeleça Enquanto que o SOAP especifica a comunicação entre um cliente e um servidor o WSDL descreve os serviços oferecidos A versão atual é 20 a versão 11 não foi endossada pelo W3C A WSDL 12 foi renomeada para 20 e aceita todos os métodos de requisição HTTP não apenas GET e POST WSDL A Web Services Definition Language WSDL é um vocabulário XML para criar contratos de serviços Cada Web Service é definido por um contrato WSDL O contrato WSDL contém toda a informação necessária para criar um cliente capaz de comunicar com o Web Service Existem várias ferramentas capazes de criar clientes de Web Services de forma automática sendo o JAXWS uma delas O contrato WSDL indica quais as operações disponibilizadas pelo Web Service aos seus clientes O conjunto das operações é designado por interface Para cada operação são especificados os argumentos inputs os resultados outputs e os erros faults Os tipos de dados dos argumentos resultados e erros são descritos com esquemas XSD WSDL O que o serviço faz Como o serviço pode ser acessado Onde o serviço pode ser acessado WSDL O contrato WSDL não é fácil de ler não só porque é extenso mas também porque a sua organização está invertida e tem múltiplas dependências WSDL O primeiro aspecto a perceber é que existe uma separação entre interface abstrata e interface concreta A interface abstrata port type define as operações e mensagens A interface concreta port faz o vínculo de interface a um conjunto concreto de tecnologias Esta separação permite que um mesmo Web Service possa ser implementado com tecnologias alternativas Na prática a vinculação binding mais comum é com SOAP e HTTP httpdisciplinastecnicoulisboaptleicsod20172018labs05wswsdl indexhtml WSDL Elementos definitions elemento raiz types define os tipos de dados utilizados pelo serviço Web pode referenciar um XSD messages especifica as mensagens usadas na comunicação com o serviço Web portType define um conjunto de operações que são executadas por um serviço binding associa um protocolo ao serviço service especifica o endereço de rede no qual o serviço pode ser acessado WSDL Estrutura xml version10 encodingUTF8 definitions namePrevisaoDoTempo targetNamespacehttpufscbrprevisao xmlnstnshttpufscbrprevisao xmlnsxsdhttpwwww3org2001XMLSchema xmlnssoaphttpwwww3org200311wsdlsoap12 xmlnshttpwwww3org200311wsdl types message namegetTemperaturaMinima message namegetTemperaturaMinimaResponse message namegetTemperaturaMaxima message namegetTemperaturaMaximaResponse portType nameTempo binding nameTempoPortBinding typetnsTempo service nameTempoService definitions WSDL Definição de Tipos em um XSD xsschema xmlnstnshttpufscbrprevisao xmlnsxshttpwwww3org2001XMLSchema version10 targetNamespacehttpufscbrprevisao xselement namegetTemperaturaMinima typetnsgetTemperaturaMinima xselement namegetTemperaturaMinimaResponse typetnsgetTemperaturaMinimaResponse xscomplexType namegetTemperaturaMinima xssequence xselement namelocalidade typexsstring minOccurs0 xssequence xscomplexType xscomplexType namegetTemperaturaMinimaResponse xssequence xselement namereturn typexsfloat xssequence xscomplexType xsschema WSDL Definição de Mensagens message namegetTemperaturaMinima part nameparameters elementtnsgetTemperaturaMinima message message namegetTemperaturaMinimaResponse part nameparameterselementtnsgetTemperaturaMinimaResponse message message namegetTemperaturaMaxima part nameparameters elementtnsgetTemperaturaMaxima message message namegetTemperaturaMaximaResponse part nameparameters elementtnsgetTemperaturaMaximaResponse message WSDL Definição de Porta portType nameTempo operation namegetTemperaturaMinima input messagetnsgetTemperaturaMinima output messagetnsgetTemperaturaMinimaResponse operation operation namegetTemperaturaMaxima input messagetnsgetTemperaturaMaxima output messagetnsgetTemperaturaMaximaResponse operation portType WSDL Binding com o Protocolo SOAP binding nameTempoPortBinding typetnsTempo soapbinding transporthttpschemasxmlsoaporgsoaphttp styledocument operation namegetTemperaturaMinima soapoperation soapAction input soapbody input output soapbody output operation operation namegetTemperaturaMaxima soapoperation soapAction input soapbody input output soapbody output operation binding WSDL Definição de Serviço service nameTempoService documentationServiço de Previsão do Tempodocumentation port nameTempoPort bindingtnsTempoPortBinding soapaddress locationhttpufscbrprevisaoTempoService port service Exemplo WSDL binding nameMyBinding typetnsabc soapbinding stylerpc transporthttpschemasxmlsoaporgsoaphttp operation nameMyOperation soapoperation soapAction input mimemultipartRelated mimepart soapbody partspart1 part2 useencoded namespacehttpmynamespace encodingStylehttpschemasxmlsoaporgsoapencoding mimepart mimepart mimecontent partattch typetexthtml mimepart mimemultipartRelated input operation binding WSDL Nesse tipo de extensão do WSDL Deve haver um atributo part nesse exemplo attch da mensagem de entrada para a operação nesse exemplo MyOperation Pode haver outras partes de entrada para MyOperation que não sejam anexos Na entrada de ligação deve haver uma marcação soapbody ou uma marcação mimemultipartRelated mas não ambas Para mensagens MIME a tag soapbody está dentro de uma tag mimepart Deve haver apenas uma tag mimepart que contém uma tag soapbody na entrada de ligação e também não deve conter uma tag mimecontent porque o tipo de conteúdo de textxml é assumido para a tag soapbody Pode haver vários anexos em uma mensagem MIME cada um descrito por uma tag mimepart Cada tag mimepart que não contém uma tag soapbody contém uma tag mimecontent que descreve o próprio anexo O atributo type dentro da tag mimecontent não é verificado ou utilizado pelo barramento de integração de serviço Ele está lá para sugerir ao aplicativo que usa o barramento de integração de serviços o conteúdo do anexo Várias tags mimecontent dentro de uma única tag mimepart significa que o serviço de backend espera um único anexo com um tipo especificado por uma das tags mimecontent dentro dessa tag mimepart O atributo parts O atributo dentro da tag soapbody é assumido como contendo os nomes de todas as partes SOAP na mensagem mas não as partes do anexo Se houver apenas partes de anexo especifique parts cadeia vazia Se você omitir o atributo parts junto o barramento de integração de serviços assumirá TODAS as partes incluindo os anexos que fazem com que os anexos apareçam duas vezes SOAP Existem diversas bibliotecas escritas em PHP para criação de web services SOAP Porém a melhor é a extensão SOAP nativa para PHP Esta extensão requer outra extensão chamada libxml que já vem instalada por padrão nas versões mais recentes do PHP Portanto para instalar a extensão SOAP no Linux basta compilar o php com a opção enablesoap compilando a partir do código fonte Se necessário Para instalar a extensão SOAP no Ubuntu basta fazer sudo aptget install phpsoap No Windows a extensão SOAP já vem habilitada por padrão SOAP Prós Processamento e chamada assíncronos Contratos formais Trabalha sobre qualquer protocolo de comunicação Pode ser escrito totalmente com WSDL Alta confiabilidade Segurança e autenticação são intrínsecos SOAP Contras Complexidade Permite apenas formato XML Requer mais recursos Engessado Difícil de ler SOAP Envelope Envelope SOAP Cabeçalho header Corpo body Dados da mensagem específica Erro fault opcional SOAP Envelope O envelope é o container de toda a mensagem SOAP Ele pode conter a declaração de namespace que indica a versão de SOAP usada Uma versão incorreta gera um erro do tipo versionMismatch Contém também um atributo que define o estilo de codificação encoding style O encoding style é uma URI Exemplo httpwwww3org200112soapencoding que define como os dados são representados no documento XML SOAP Envelope O cabeçalho header possui informações de controle e processamento Ele é opcional e carrega informações adicionais como por exemplo se a mensagem deve ser processada por um determinado nó intermediário É importante lembrar que ao trafegar pela rede a mensagem normalmente passa por diversos pontos intermediários até alcançar o destino final Se utilizado o header deve ser o primeiro elemento do envelope O corpo body é a mensagem de fato payload Contém informação a ser transportada para o seu destino final O erro fault é um elemento opcional com informações e status de erro da mensagem Observe abaixo um exemplo de envelope SOAP Envelope SOAP xml version10 encodingutf8 soapEnvelope xmlnsxsihttpwwww3org2001XMLSchemainstance xmlnsxsdhttpwwww3org2001XMLSchema xmlnssoaphttpwwww3org200305soapenvelope soapHeadersoapHeader soapBodyCORPO DA MENSAGEM SOAPsoapBody soapEnvelope UDDI É um protocolo que foi criado para facilitar a arquitetura orientada a serviços via web services O UDDI é um mecanismo que permite que os servidores registrem ou publiquem seus webservices em um diretório de forma que os clientes possam encontrálos com facilidade O UDDI é o protocolo que implementa a nossa lista telefônica como uma metáfora para o Registro de serviços O fato de estar disponível um web service de consulta à previsão do tempo não significa necessariamente que os clientes saibam que ele exista Com o UDDI os clientes podem consultar os web services que estão disponíveis na rede por meio de um protocolo padronizado e assim poder invocálos facilmente UDDI Registros UDDI são documentos XML que contêm essencialmente metadados sobre os serviços Esses metadados são principalmente o nome dos web services além dos nomes das operações de cada web service bem como os respectivos argumentos e retornos de cada operação Os Registros de serviços UDDI podem ser públicos se forem disponibilizados na www internet Neste caso qualquer um poderá acessar seu diretório e descobrir o que está registrado nele Contudo o mais comum é que os Registros de serviços UDDI sejam privados isto é visíveis somente no âmbito da intranet de uma organização SOAP PHP O PHP disponibiliza duas principais classes para trabalhar com SOAP SoapClient classe cliente para acessar web services disponíveis por outras aplicações SoapServer para criar novos webservices e disponibilizálos para outros aplicativos SOAP PHP Nesta aula Vamos criar uma pequena aplicação SOAP exemplificando a comunicação entre cliente e servidor Como vimos anteriormente nosso servidor SOAP precisa de um arquivo XML chamado de WSDL que especifica os métodos presentes em nosso web service Porém criar um arquivo WSDL manualmente é muito complexo Infelizmente a classe nativa do PHP SoapServer não gera o arquivo WSDL automaticamente SOAP PHP No PHP é possível operar no modo não WSDL ou seja sem a necessidade de existir um arquivo WSDL Neste modo o cliente de web service não conseguirá obter informações importantes por exemplo o tipo de dados formatação etc Assim operar no modo não WSDL não é recomendado Muitas plataformas como NET Java ou Ruby necessitam de um WSDL para poderem funcionar No PHP para gerar WSDL você tem disponível algumas ferramentas que auxiliam esse trabalho Servidor SOAP PHP php options arrayuri http127001soapserver server new SoapServernull options serversetClassSoapServerExemplo O método handle processa a requisição SOAP e envia uma resposta para o cliente serverhandle class SoapServerExemplo public function mensagemnome return Boas Vindas nome public function somaa b return a b Criamos a instância do SoapServer A opção uri indica o namespace do webservice no servidor O primeiro parâmetro null indica que estamos trabalhando com um webservice no modo não WSDL Informamos a classe em que o webservice irá se basear Podemos usar também o método addFunction para adicionar funções em nosso webservice A classe SoapServerExemplo será disponibilizada em nosso webservice Portanto temos disponíveis no webservice os métodos mensagem e soma Cliente SOAP PHP php Criamos a instância de nosso cliente de webservice Especificamos a localização e o namespace do servidor de webservice Passando null no primeiro parâmetro do construtor indicamos que o webservice irá trabalhar no modo não WSDL options array location http127001soapserverserverphp uri http127001soapserver client new SoapClientnull options No Objeto client podemos usar os métodos da classe SoapServerExemplo disponível em nosso webservice echo clientmensagemDouglas br echo clientsoma3 5 br Resultado SOAP PHP Boas Vindas Douglas 8 Cliente SOAP PHP consumindo WSDL php clientpuro new SoapClienthttpsappscorreioscombrSigepMasterJPAAtendeClienteService AtendeClientewsdl ceparraycep 81750270 resultadoclientpuroconsultaCEPcep echo Consulta por CEP no webservice sigep dos correios echo brEndereço resultadoreturnend echo br Complemento resultadoreturncomplemento echo brComplemento2 resultadoreturncomplemento2 echo brBairro resultadoreturnbairro echo brEstado resultadoreturnufecho brCEP resultadoreturncep echo brID resultadoreturnid Cliente SOAP PHP httpswwwyoutubecomwatchve7jDqN2AY httptalksphpnetshowsoap12 httpswwwcomputersciencemastercombrexercicioswebservicescommanutencaodeestadophp httpsgistgithubcomumidjons5907857 httpsdevtutgithubiophpsoapclienthtmltracingsoaprequestandresponse httpswwwthecannonhutcomwebservicessoapindexhtml httpsdurakorgseanpubssoftwarephp743soapclientsoapclienthtml httpwwwherongyangcomWebServicesPHPSOAPServerWSDLExampleHelloServerWsdlhtml httpwwwherongyangcomWebServicesPHPSOAPServerExampleHelloServerhtml httpswwwdelftstackcomhowtophpphpsoapexamples REST REST é abreviação de Representational State Transfer ou em português Transferência de Estado Representacional O REST difere bastante de outros métodos de web service como SOAP ou XMLRPC Primeiro que ele não é um padrão W3C ou qualquer outro REST não possui WSDL Não existem frameworks classes nativas ou extensões PHP para criação de servidores ou clientes REST REST REST na verdade pode ser considerado como um conjunto de princípios que quando aplicados de maneira correta em uma aplicação a beneficia com a arquitetura e padrões da própria Web Ferreira 2017 REST Como Surgiu Foi descrito por Roy Fielding um dos principais criadores do protocolo HTTP em sua tese de doutorado e que foi adotado como o modelo a ser utilizado na evolução da arquitetura do protocolo HTTP Ferreira 2017 REST Arquitetura Request httpmyservertasks HTTP GET Response 200 OK Client Server Resources xml Mediatype Quem usa REST Twitter usa REST eBay e Amazon têm serviços web para REST e SOAP O Sharepoint 2013 apresenta novos endpoints REST para quase todas as APIs no modelo de objeto do cliente HTTP O HTTP possui operações para transferência de representações entre clientes e servidores Em HTTP GET POST PUT e DELETE são operações em recursos O uso adequado do HTTP elimina a necessidade de operações de invenção como createOrder getStatus O SOAP usa HTTP como protocolo para transportar mensagens mas faz uso insatisfatório de operações HTTP REST Básico Ao contrário de SOAP e XMLRPC REST não requer um novo formato de mensagem A API HTTP é CRUD Criar Recuperar Atualizar e Excluir GET me dê algumas informações Recuperar POST aqui estão algumas informações de atualização Atualização POST para criar novos recursos também PUT aqui estão algumas novas informações Criar Quando você dá suporte a PUT para criar novos recursos os clientes devem poder atribuir URIs para recursos DELETE excluir alguma informação excluir REST Básico Exemplo Por exemplo a URL http127001usuario28 pode ser um recurso Chamar essa URL através do método GET representa que queremos obter detalhes desse usuário Chamar através do método POST indica que queremos criar um novo usuário Chamar através do método PUT indica que queremos atualizar o registro de um usuário e Chamar através o método DELETE pode ser usado para excluir determinado usuário REST Básico persons Operations about users of the system POST persons Create a new user in the database Note JSON representation of a new users data should be contained in the body GET persons Return a list of all users in the database GET personsusername Return a user by supplying a unique user name PUT personsusername Update an existing user in the database Note the JSON representation of the user should be supplied in the body along with the users user id DELETE personsusername Delete an existing user whos unique username is supplied REST Fundamentos Arquitetura baseada em recursos Um recurso é acessado por meio de uma interface comum baseada nos métodos padrão HTTP Identifique cada recurso usando um URL Cada recurso deve suportar as operações comuns de HTTP REST permite que os recursos tenham diferentes representações por exemplo texto xml json etc O restante cliente pode solicitar uma representação específica através do protocolo HTTP Negociação de Conteúdo REST Fundamentos REST SOAP Transport must be HTTP or HTTPS Normally HTTPHTTPS but can be something else Response data transmitted as any format Transmitted as XML Request is transmitted as URI Lightweight and URI indicate the intend Transmitted as XML To understand the intent must analyse message body Easy to call from JavaScript Need JS parsing for XML Easy to build Development tools are available REST Fundamentos REST SOAP simples simples overhead de comunicação overhead de comunicação Uniform contract Cada serviço tem seu contrato WSDL específico Stateless Stateful Sem controle de transação Com controle de transação segurança segurança JSON JavaScript Object Notation é um formato leve de intercâmbio de dados Usado para transmitir dados entre um servidor e uma aplicação web servindo como alternativa ao XML firstName John lastName Smith age 25 address streetAddress 21 2nd Street city New York state NY postalCode 10021 phoneNumber type home number 212 5551234 type fax number 646 5554567 JSON vs XML Diferenças entre JSON e XML JSON XML No validation scheme XSD Fast parsing just as Eval Required xml doc parsing In JavaScript we can work as objects In JavaScript we work as strings JSON vs XML Diferenças entre JSON e XML Designing REST service Ao projetar um serviço REST devemos seguir os seguintes princípios de design Use métodos HTTP explicitamente Seja sem estado stateless Exponha URIs semelhantes à estrutura de diretórios Use o tipo de conteúdo adequado Use métodos explícitos HTTP Use métodos HTTP explicitamente da maneira que segue o protocolo definido pela RFC 2616 Examplo Use GET para recuperar apenas o recurso Uso inválido GET addusernameRobert HTTP11 Para HTTP11compliant Web servers usar GET para este uso é inconsistente Use métodos explícitos HTTP Segurança e idempotência de métodos HTTP Método Segurança Idempotência GET YES YES PUT NO YES DELETE NO YES POST NO NO Em HTTP não se espera que métodos seguros causem efeitos colaterais Implemente métodos seguros como operações somente leitura Seguro o cliente pode fazer um pedido sabendo que não vai mudar o estado do recurso A idempotência garante aos clientes que repetir uma solicitação tem o mesmo efeito que fazer uma solicitação apenas uma vez Use métodos explícitos HTTP Qualquer cliente deve poder fazer solicitações de métodos SAFE quantas vezes forem necessárias Se a implementação de um servidor causar efeitos colaterais inesperados ao processar essas solicitações método seguro é justo concluir que a implementação de HTTP do servidor está incorreta Em implementações de cliente sempre que você encontrar um software ou uma falha de rede para um método idempotente você pode implementar a lógica para tentar novamente a solicitação Seja Stateless Para atender o serviço de alto desempenho deve distribuir entre os servidores O uso de servidores intermediários requer que os clientes do serviço Web REST enviem solicitações completas e independentes O que permite que as solicitações sejam encaminhadas de um servidor para outro conforme necessário para diminuir o tempo de resposta geral de uma chamada de serviço da Web Expor URIs do tipo estrutura de diretório A URI deve ser direta previsível e de fácil compreensão Pense em um URI como um tipo de interface de auto documentação Com URIs do tipo estrutura de diretórios podemos conseguir isso O URI é hierárquico enraizado em um único caminho ramificação para subcaminhos que expõem as principais áreas do serviço Exemplo httpwwwmyserviceorgdiscussiontopicstopic httpwwwmyserviceorgdiscussion20081210topic Use o tipo de conteúdo adequado Decida o formato de conteúdo a ser veiculado ao projetar seu serviçorecursos Dê aos aplicativos cliente a capacidade de solicitar um tipo de conteúdo específico que seja mais adequado para eles Vantagens REST Eles são altamente reutilizáveis em todas as plataformas Java NET PHP etc pois dependem do protocolo HTTP básico Eles usam XML básico em vez do XML SOAP complexo e são facilmente consumíveis Reduz a complexidade de serialização e desserialização Resultados leveslegíveis para humanos Fácil de construir não são necessários kits de ferramentas Onde está o WSDL WSDL é legível por máquina mas REST é legível por humanos Não há ferramenta útil para converter WSDL em código WSDL 11 foi inadequado para descrever comunicações com HTTP e XML O WSDL 20 foi projetado com serviços Web REST em mente REST with WCF WCF é independente de protocolo mas usa SOAP O WCF é totalmente compatível com REST desde o NET Framework 35 SystemServiceModelWeb assembly WebGetAttribute Respond to HTTP GET requests WebInvokeAttribute Respond to HTTP POSTother requests binding WebHttpBinding behavior WebHttp Behavior REST Prós Agilidade Flexibilidade Praticidade Simplicidade Leveza Escalabilidade REST Contras Implementações Lorest Limitações das linguagens de programação recursos Underfetching Overfetching Flexibilidade falta de entendimento REST Contras REST é abreviação de Representational State Transfer ou em português Transferência de Estado Representacional O REST difere bastante de outros métodos de web service como SOAP ou XMLRPC Primeiro que ele não é um padrão W3C ou qualquer outro REST não possui WSDL Não existem frameworks classes nativas ou extensões PHP para criação de servidores ou clientes REST A documentação das APIs Swagger Detalhe Programa de Erradicação do Trabalho Infantil Peti MostrarEsconder Listar operações Expandir operações GET apidedadospetiporcpfounis Consulta os registros Programa de Erradicação do Trabalho Infantil por CPFNIS Notas de Implementação Filtros mínimos Página padrão 1 CPF NIS Classe de resposta Status 200 OK Modelo Example Value beneficiario codigoFormatado string cpf string cpfFormatadoComSigilo string cpfnis string id 0 municipio codigoIBGE string nomeUFSE string Tipo de conteúdo da resposta Parâmetros Parâmetro Valor Descrição Tipo de parâmetro Tipo de dados codigo required CPFNIS query string pagina 1 Página consultada query integer Mensagens de resposta Código de status HTTP Razão Modelo resposta Cabeçalhos 401 Unauthorized 403 Forbidden 404 Not Found Tente agora