SóProvas


ID
1823086
Banca
CESPE / CEBRASPE
Órgão
TRE-PI
Ano
2016
Provas
Disciplina
Arquitetura de Software
Assuntos

Acerca de REST (representational state transfer), assinale a opção correta.

Alternativas
Comentários
  • Alguém poderia comentar?!

  • a) Errada

    b) GET – recupera informações sobre o recurso identificado pela URI. Ex: listar produtos, visualizar o produto 45. Uma requisição GET não deve modificar nenhum recurso do seu sistema, ou seja, não deve ter nenhum efeito colateral, você apenas recupera informações do sistema.

    c) O REST não possui este comando

    d) CORRETA

    e) Rest não possui este comando

  • Rest modelo rígido?

     

    A idea do REST é justamente não ser rígido com o WebService faz com WSDL

     

    Na boa, a menos errada é a letra B.. pq não é o certo, mas dá pra alterar recursos com GET

     

    também o recursos não são rígidos, a evolução deles pode ser via URL ou via media type 

     

    enfim

  • D) REST é um modelo rígido ao se compreender que cada recurso possuir seu próprio URI. Cada recurso tem seu próprio identificador, como http://www.exemplo.org/cidade/brasilia.

    Note-se que o HTTP não proporciona nenhum recurso padrão para descobrir recursos – não há nenhuma operação LIST ou FIND em HTTP, que se corresponda às operações list*() e find*() como por exemplo em RPC. No seu lugar, as aplicações baseadas em dados REST resolvem o problema, tratando uma coleção de resultados de busca como outro tipo de recurso, o que requer que os engenheiros de software desenhem na aplicação colocando URLs adicionais para mostrar ou encontrar cada tipo de recurso. 

    Isso justifica a alternativa letra D. 

    FONTE: https://www.wikiwand.com/pt/REST

     

     

     

     

     

  • A alternativa D é no mínimo ambígua.

     

    A única doutrina válida sobre REST é essa aqui:

    http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

     

    O resto publicado por aí é balela.

     

    Repare que na definição do criador do REST, que consta no link acima, define-se:

     

    "5.2.1.1 Resources and Resource Identifiers

    More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent. The values in the set may be resource representations and/or resource identifiers. A resource can map to the empty set, which allows references to be made to a concept before any realization of that concept exists -- a notion that was foreign to most hypertext systems prior to the Web [61]. Some resources are static in the sense that, when examined at any time after their creation, they always correspond to the same value set. Others have a high degree of variance in their value over time. The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another."

     

    Assim, apenas a semântica da localização é rígida, mas a localização em si e o estado de cada recurso/entidade/instância pode variar no tempo.

  • Assim como alguns colegas mencionaram, também não gostei dessa definição de modelo "rígido" para REST, uma vez que, busca-se ser mais flexível do que o SOAP.

     

    Contudo... geralmente essas afirmações estão embasadas em alguma fonte, e eis que acredito ter encontrado a 'culpada'...

     

    REST significa “REpresentational State Transfer”, uma arquitetura de comunicação entre aplicações baseada em um modelo rígido de recursos e localizações.

    Fonte: Java Enterprise Edition 6 - Desenvolvendo Aplicações Corporativas, 2011 - CLEUTON SAMPAIO

  • Complicado, mas a menos errada é realmente a letra D). Nunca ouvi falar de GET sendo usado pra modificar recursos.